Often times during a conference call, a participant to the conference call may place the call on hold to attend to some other activity. Sometimes the participant may have a music-on-hold feature that causes a server to provide music to the rest of the conference participants while the user is on hold. Sometimes, when Session Initiation Protocol (SIP) is used, the server providing the on-hold music is joined to the conference via utilization of an INVITE/Replace, which causes the server to replace the endpoint that has placed the conference on hold. Unfortunately, there are many instances where the music-on-hold is played when the participant places any call on hold. While music-on-hold is useful for two person communications, it can be quite annoying for multi-party communications when the remaining participants still want to communicate but have to do so over the music-on-hold.
Present solutions to this problem are limited in two ways. First, present solutions are implemented at the conference bridge, which generally means that they can only be implemented when a conference is hosted on a conferencing server that has a significant amount of processing capabilities. Present solutions are not readily implemented on conferences which are hosted locally (e.g., where a communication endpoint owns the conference and mixes the various inputs of the participants).
Second, present solutions absolutely remove music-on-hold during a conference. This is limited because there may be instances during a conference in which it is desirable to hear the music-on-hold (or similar indicator) so that participants know the other person has placed them on hold and has not disconnected. It is only desirable, however, when there is silence to be filled.